Embedded software update system

ABSTRACT

A method and system for an embedded software update system, which helps manufactures or vendors avoid costly product recall activities in the event their digital products have field software errors (“bugs”) or hardware problems. One aspect of the present invention is directed to an error correction system, which remotely corrects these software errors and minimizes influences of hardware problems. Another aspect of the present invention is directed to a software updating system, which is capable of updating software modules in the digital products by use of software patches. The software patch system of the present invention facilitates manufactures&#39; transmitting software patches to the “on-the-fly” digital products to fix software errors and minimize influences of hardware problems. The software patch may also contain new parameters for updating some data area in NVM (Non Volatile Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory) memory of a digital product, which is quite useful when service providers or manufactures want to modify some service features or product features.

RELATED APPLICATION

[0001] The present application claims priority from provisionalapplications, Application No. 60/305,704, entitled “Embedded SoftwarePatch System”, filed on Jul. 16, 2001, and No. 60/354,915, entitled“Embedded Software Patch System”, filed Feb. 8, 2002. The priorapplications are hereby incorporated into this application by referenceas if fully set forth herein.

FIELD OF THE INVENTION

[0002] The present invention is related to digital electronics productswith embedded software operating systems, and more particularly relatedto a system and method of updating, correcting, modifying or upgradingthe embedded software in such digital products before or after theproducts have been released to market by use of software patches.

ART BACKGROUND

[0003] Progress and innovation in digital technology have changed howpeople live, work or play. The miniaturization of computers, cellularphones, personal digital assistances (“PDA”), simple pagers, PCMCIAwireless modem cards, or other wireless modem cards using publicstandard or proprietary I/O connectors offer prime examples of howtechnology makes themselves more and more indispensable. Together, theyhelp people work more efficiently and productive, stay connected withloved ones and have more access to information and entertainment.

[0004] For the digital products, such as cellular phones, PDAs andset-top boxes, their digital technology is based on large-scale embeddedsoftware system. Embedded software systems in those digital productsnormally have more than tens of thousands of lines in their sourcecodes. And inevitably, software bugs exist in these embedded softwaresystems that may cause malfunctions in the digital products. Some bugsthat are so fatal may even force manufactures to recall their digitalproducts. Due to the cost involved in a product recall, somemanufactures have decided to avoid certain market space altogether, orat least until production quality and reliability improve. Of course,the resulting public-relations (“PR”) nightmare and potential loss ofconsumer confidence also play a significant role in their decisions.

[0005] Despite improvement in various stages of digital productdevelopment and manufacturing, defects are invariably part of theprocess. Further, as digital products become more advanced and complex,they are more vulnerable to bugs or defects in software, hardware,material or manufacturing. Many preventive measures can be implementedto minimize or detect defects before the products are released to theend users. However, once the digital products are released to the field,efforts to fix bugs or defects may become a potential recall nightmare.For defects occurring in limited lots, the end users may be asked toreturn the products for service or replacement. The end users maytolerate such inconvenience if it rarely occurs and if the vendorsprovide loan units for the time being.

[0006] For defects in massive scales involving many lots, the end usersmay still be asked to bring the digital products back for service orreplacement. However, in such massive scales, the vendors may not evenhave enough resources to timely repair or replace the defective units.While loaners can be offered to the end users for the duration, thevendors must first have that many units in stock for temporary usage bythe end users. Such temporary usage presents a loss of revenueopportunity for those units in stock, since the vendors cannot put themin their ordinary and profitable use.

[0007] Additionally, even after a digital product has been released tothe field, manufactures will sometimes go through improvement,enhancement or upgrades, which may require a change in the embeddedsoftware. For major changes, manufactures may generate a new round ofproduct release, which may be costly but necessary. However, for minorchanges, they are confronted with the choice of having to go through apremature product release, or holding off until there are many minorchanges to be made. A premature and untimely product release drains thecompany's resources, while holding off risks antagonizing the end userswho might complain about the minor inconvenience.

[0008] Therefore, it is desirable to minimize product recall for thosedigital products based on embedded software systems.

[0009] It is also desirable to minimize intermediary product releasesfor those digital products.

[0010] It is also desirable to be able to fix, repair, update, upgradeor enhance those digital products with reduced rounds of productrelease.

SUMMARY OF THE PRESENT INVENTION

[0011] The present invention is directed to a method and system for anembedded software update system, which helps manufactures or vendorsavoid costly product recall activities in the event their digitalproducts have field software errors (“bugs”) or hardware problems. Oneaspect of the present invention is directed to an error correctionsystem, which remotely corrects these software errors and minimizesinfluences of hardware problems. Another aspect of the present inventionis directed to a software updating system, which is capable of updatingsoftware modules in the digital products by use of software patches. Thesoftware patch system of the present invention facilitates manufactures'transmitting software patches to the “on-the-fly” digital products tofix software errors and minimize influences of hardware problems. Thesoftware patch may also contain new parameters for updating some dataarea in NVM (Non Volatile Memory), EEPROM (Electrically ErasableProgrammable Read-Only Memory) memory of a digital product, which isquite useful when service providers or manufactures want to modify someservice features or product features.

[0012] The software update system of the present invention hasadvantages over the conventional software upgrade/updating systems. Thesoftware update system only needs comparatively small memory space tosave software patches for bug fixes, or for key modules update. This isparticularly advantageous to the small, portable digital products,whereas conventional software update/upgrade systems require largememory space to contain the whole application data of a new softwareversion received for upgrade.

[0013] The proposed update system requires only limited networkresources for patch data transmission, since each patch size is normallyvery small, whereas conventional software upgrade/updating systemsrequire much more bandwidth or network resources for transmitting thebig blocks of application data for software version updating.

[0014] Due to the ever-increasing pace for technology advancement indigital products, new standards, specifications and service features arebeing upgraded much sooner than before. Such upgrade would normallyrequire new digital hardware to support the new advanced features.Another aspect of the software patch system of the present inventionmakes it simpler and more economic to do upgrades through software, thusminimizing the need to do frequent hardware changes. Additionally, thesoftware update system of the present invention can be added to fixproblems hidden in the operating system that support applicationdownloading, such as Java Virtual Machines, or BREW (“Binary RuntimeEnvironment for Wireless”).

[0015] A further aspect of the present invention separates embeddedsoftware intended for digital products into multiple sections and onlyupdates the necessary sections. This approach is advantageous over theconventional approach of having to update the total system, since itwill optimize usage of resources for network transmission.

[0016] Hardware designs for CPU, MCU or DSP processors may also includethe mechanism of checking update software in accordance with the presentinvention before running a software section. CPU/MCU/DSP can be designedin such a way that it is capable of automatically checking softwareupdate information while running the embedded software, andautomatically jumping to the updated code address when software updateis available.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017]FIG. 1 illustrates a simplified diagram of a conventionalmicroprocessor system in a digital product.

[0018]FIG. 2 illustrates a simplified diagram of a conventional DSPsystem in a digital product.

[0019]FIG. 3 illustrates an exemplary software architecture of a patchsystem in a digital product.

[0020]FIG. 4 illustrates a simplified diagram of an exemplary softwaresectioning and Update-Processing-Routine allocation of the originalembedded software in a digital product.

[0021]FIG. 5 illustrates an exemplary design and implementation ofsoftware update based on software sections in accordance with oneembodiment of the present invention.

[0022]FIG. 6 illustrates an exemplary design and implementation ofsoftware update using JUMP to patch program through Patch ControlRoutine in accordance with another embodiment of the present invention.

[0023]FIG. 7 illustrates an exemplary design and implementation ofsoftware update using JUMP to patch program through Patch-Control-Blockin accordance with yet another embodiment of the present invention.

[0024]FIG. 8 illustrates exemplary communication layers for patchtransmission in accordance with one embodiment of the present invention.

[0025]FIG. 9 illustrates an exemplary format of the patch data and patchdata packets in accordance with one embodiment of the present invention.

[0026]FIG. 10 illustrates an exemplary state diagram of patchprogramming in accordance with the present invention.

[0027]FIG. 11 illustrates an exemplary architecture for a patch serverin accordance with the present invention.

[0028]FIG. 12 illustrates an exemplary design of patch transmissionusing SMS messages.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0029] 1. A method and system for an embedded software update system fordigital products is disclosed. In the following detailed description,numerous specific details are set forth to provide a full understandingof the present invention. It will be obvious, however, to one ordinarilyskilled in the art that the present invention may be practiced withoutsome of these specific details. In other instances, well-knownstructures and techniques have not been shown in detail so as to avoidunnecessarily obscuring the present invention. Additionally, headingsare used throughout the description as a matter of convenience and forease of references only. It should note that what is meant by “embeddedsoftware” herein is the software program written inC/C++/Java/Assembler, or other software programming languages, as wellas any executable machine code of CPU/Microprocessor or DSP (“DigitalSignal Processor”), for operating the digital product.

[0030] 2. System Architecture

[0031] The software update system of the present invention will first bedescribed from a system architecture perspective. Reference is to FIG.1, where a simplified conventional microprocessor system is illustrated.A microprocessor system in a typical digital product may comprise a CPU(“Central Processing Unit”) 100, RAM (“Random Access Memory”) 110,FLASH/ROM memory 115, and some peripheral devices 120. A softwareprogram resides in FLASH/ROM memory 115, and is read by CPU 100 duringexecution. FLASH is a type of constantly-powered nonvolatile memory thatcan be erased and reprogrammed in units of memory called blocks. ROMstands for “Read Only Memory”.

[0032] Similar to the microprocessor system of FIG. 1, a DSP (“DigitalSignal Processor”) system in a conventional digital product may comprisea DSP core 230, RAM 240, FLASH/ROM memory 245, and some peripheraldevices 250, as shown in FIG. 2. A software program resides in FLASH/ROMmemory 45, and is read by DSP core 30 during execution.

[0033] A typical digital product, e.g. a digital cellular phone,normally contains a microprocessor system, and may also contain a DSPsystem. The software update system of the present invention can beconfigured or adapted to reside in the embedded software of themicroprocessor system and/or the DSP system of a digital product. Thesoftware update system in accordance with one embodiment of the presentinvention, when it is implemented in a digital product, may bestructured to comprise a software module 302 for patch receiving, asoftware module 304 for patch programming, a patch database 310, and apatch correction handler 320. A simplified drawing of exemplary softwarearchitecture in a digital product is illustrated in FIG. 3.

[0034] Referring to FIG. 3, the patch receiving module 302 is forreceiving software patch data. It may include mechanism for datareceiving either from wired link or wireless link, mechanism for dataerror detection and/or mechanism for data security check. After thepatch receiving module 320 correctly receives patch data, it will passthe patch data to the patch programming module 304. The patchprogramming module 304 is for writing patch data into the patch database310. It may include program for writing data into FLASH, NVM, EEPROMmemory, and/or other types of memory. The patch database 310 is a memoryarea in FLASH memory and/or other types of memory, which is forcontaining patch data. The patch correction handler 320 is for handlingprocess for using patch program instead of using original error program.It may include mechanism for jumping to the patch program area from theoriginal software code area that has errors.

[0035] 3. Software Update Technology

[0036] 3.1 Separating Software into Software Sections

[0037] To take advantage of the software update system in accordancewith one embodiment of the present invention, before an embeddedsoftware is implemented into a digital product, a plurality of locationsin the embedded software are determined at first, so that softwareupdate can be started later on from these locations. The locations canbe expressed by L1, L2, . . . , Ln, in the order from small address tolarge address, where n is the total number of the locations.

[0038] The part of the embedded software between two successivelocations, such as the part between L1 and L2, is treated as a softwaresection, S1, of the embedded software. In this way, the embeddedsoftware is effectively “separated” into a plurality of softwaresections, S1, S2, . . . , Sn, in the order from small address to largeaddress, where n is the total number of the software sections. Note thatthe last section Sn is started from Ln and ended at the end of theembedded software.

[0039] As is with any software, it may be necessary to update or modifyan embedded software from time to time. When it is necessary to updatecertain program codes, which happen to be in a software section, forexample S2, updating can be achieved by directing execution of theembedded software in section S2, beginning at location L2, to a softwarepatch. The software patch is then used for execution instead of usingthe program codes in S2. In some cases, it may be more convenient tostart updating from other locations, for example L1, directing executionof the embedded software to a software patch from L1, even if theprogram codes that need to be updated exist in S2. In other words, itmay be preferable in certain situations to direct the execution of theembedded software to a software patch earlier than the intended section.

[0040] Size of a software section may not be a fixed number, and can bevariable from one section to another, according to the different needsof different sections. Determining locations of L1, L2, . . . , Ln andpartitioning embedded software into software sections S1, S2, . . . Sn,can be based on boundaries of software functions, number of lines ofprogram lines, types of CPU/DSP instructions, software design schemes,hardware design schemes, software modification requirements, or errorcorrection requirements, as can be appreciated by those skilled in theart.

[0041] At each location of L1, L2, . . . , Ln, anUpdate-Processing-Routine is allocated for handling software update.Referring to FIG. 4, a simplified drawing of exemplary software sectionseparation and the Update-Processing-Routine allocation is illustrated.To prepare the embedded software 400, at the beginning of every section401, 402, 403 of the software 400, an Update-Processing-Routine 404,405, 406 is allocated in the section.

[0042] An Update-Processing-Routine is a software routine that handlessoftware update processing. If there is a software patch for updatingcertain program codes in a software section, for example S2, theUpdate-Processing-Routine at location L2 will direct the CPU/DSPexecution to the start address of software patch, and use the softwarepatch for execution. This process may involve a Patch-Control-Routine(to be further described in connection with FIG. 6) before jumping tothe start address of the patch. If there is no patch for updating asoftware section S2, the Update-Processing-Routine at location L2 willdirect the CPU/DSP execution to use the existing S2 program; that is,the CPU/DSP execution will continue through this routine withoutaffecting normal execution.

[0043] The content of the Update-Processing-Routines can be differentfrom one location to another location, or they can be designed in thesame way.

[0044] 3.2 Software Section-Based Software Updating

[0045] One exemplary design and implementation of software update basedon software sections is shown in FIG. 5. When there exists a softwarepatch for updating software section K 510, the Update-Processing-Routine505 of software section K, during execution of the software, directsCPU/DSP execution to jump 506 to the start address 502 of patch program507 for updating software section K. In this way, the patch program 507will be used for execution instead of original program in section K.After executing the patch program 507, the CPU/DSP instruction pointeris directed to jump 508 to a predetermined place in the originalsoftware, which typically is the place right after the program codesthat need to be updated in software section 510. As such, any bugs insoftware section 510 is bypassed by the execution of patch program 507.

[0046] Another exemplary design and implementation of software updatebased on software sections is shown in FIG. 6. When there exists asoftware patch for updating software section K 610, theUpdate-Processing-Routine 605 of software section K directs CPU/DSPexecution to jump 606 to a Patch-Control-Routine 609. ThePatch-Control-Routine 609 is a software routine that performs generalpatch execution control, such as preparation process for patch programexecution and/or determining the start address 602 of patch program 607based on current patching status and system parameters, for example, aPatch-Control-Table (to be described below). The Patch-Control-Routine609 directs CPU/DSP execution to jump 611 to the start address 602 ofpatch program 607 of updating software section K610. In this way, thepatch program 607 will be used for execution instead of original programin section K 610. After executing the patch program, the CPU/DSPinstruction pointer is directed to jump 608 to a predetermined place inthe original software, which typically is the place right after theprogram codes that need to be updated.

[0047] The aforementioned Patch-Control-Table is a list of informationthat can be used for controlling patch receiving, patch programming andpatch signaling process. This list of information may include a list ofidentifiers of the patches that have been programmed into the digitalproduct, and/or a list of the corresponding identifiers of the softwaresections that are updated by those patches. It may also includeinformation of a patch database, such as the number of bytes in thepatch program area that can be used for storing new patches. It mayinclude other information for controlling patch receiving, patchprogramming, and patch signaling processes. The Patch-Control-Table mayreside in the Patch-Control-Routine or any other area in the digitalproduct memory 600.

[0048] As can be appreciated by those skilled in the art, there may besome advantages in using an intermediate step, such as thePatch-Control-Routine 609, for directing CPU/DSP instruction pointer tojump to the start address 602 of patch program 607 as shown FIG. 6,instead of directly jumping to the start address 502 of patch program507 as shown in FIG. 5. If a new patch is necessary for the softwaresection that already has a patch for updating, the section identifier ofthat existing patch can be deleted (e.g., set to zero) at aPatch-Control-Table that is handled by the Patch-Control-Routine 609,while the new patch can be programmed into the Patch-Control-Table withthe original section identifier but with different Patch Identifierand/or patch start address. In this way, the Patch-Control-Routine 609will be able to determine the corresponding new start address of patchprogram from the Patch-Control-Table, and direct CPU/DSP instructionpointer to jump to the new patch program.

[0049] Memory area for containing patch program codes can be allocatedat a place outside of the embedded software code area. It can also beallocated at a place inside of the embedded software code area. Forexample, a memory area in FLASH memory can be reserved as a data area ora data buffer filled with bytes of hexadecimal number “0×FF” in asoftware program, and this memory can be allocated in the embeddedsoftware code area and can be used to contain patch program codes bychanging/overwriting these bytes of hexadecimal number “0×FF” to patchprogram codes.

[0050] 3.3 Designing Update-Processing-Routine

[0051] The methodology in connection with the design and implementationof the Update-Processing-Routines will now be discussed in the followingsections.

[0052] 3.3.1 Designing Update-Processing-Routine usingPatch-Checking-Routine

[0053] One exemplary design and implementation of theUpdate-Processing-Routine is to use patch flags or patch checkingroutines. In this way, each software section will have a correspondingpatch flag and/or a patch checking routine to show whether there is apatch in the patch area for updating this section.

[0054] When there is no corresponding patch programmed in the patch areafor updating, the Update-Processing-Routine can be shown as followsusing program description language, which can readily be translated intoC/C++/Java/Assembler and other software programming languages, orexecutable machine code of CPU/Microprocessor and DSP:  (At thebeginning of a software section.)  Patch-Checking-Routine  If (thePatch-Checking-Routine declares that there is a patch for updating thissection) {  Patch-Correction-Routine } ORIGINAL SECTION CODE.

[0055] As shown, a Patch-Checking-Routine is used in the above program.The Patch-Checking-Routine is a software routine to check whether thereis a patch in the patch area for updating this section of the embeddedsoftware. It may check some patch flags or some system parameters, oruse some software functions to detect whether there is a patch forupdating this software section.

[0056] The Patch-Correction-Routine is a software routine to directCPU/Microprocessor or DSP to use patch program instead of using originalsection code. The Patch-Correction-Routine may include a pre-processwhen it is necessary for making preparation for jumping to the patchprogram, such as saving some parameters or performing some parameter andfunction setup. The Patch-Correction-Routine also includes someinstructions for directing CPU/Microprocessor or DSP instruction pointerto the start address of patch program as shown in FIG. 5, or to aPatch-Control-Routine as shown in FIG. 6. The benefits of using thePatch-Control-Routine have been discussed in Section 3.2.

[0057] 3.3.2 Designing Update-Processing-Routine using Jump/BranchInstructions

[0058] Another exemplary design and implementation of theUpdate-Processing-Routine is to use the JUMP (or BRANCH in ARM®parlance) command or similar CPU/DSP instructions. It should be notedthat JUMP, a well-known concept in computer programming, is used as ageneric term in this application, which means directing execution ofCPU/DSP from one location to another location.

[0059] When there is no corresponding patch programmed in the patch areafor updating the software section, the Update-Processing-Routine can beshown as follows, using program description language, which can readilybe translated into C/C++/Java/Assembler and other software programminglanguages, or executable machine code of CPU/Microprocessor and DSP: (Atthe beginning of a software section, in case of no patch programmed)Jump to Label_O Label_P: Patch-Correction-Routine Label_O: ORIGINALSECTION CODE

[0060] When there is no corresponding patch programmed in the patch areafor updating the software section, the first instruction of theUpdate-Processing-Routine is to JUMP to Label_O, which is the startaddress of the original code of the section.

[0061] When there is a corresponding patch programmed in patch area forupdating the software section, the first instruction of theUpdate-Processing-Routine will be changed, so that CPU/DSP instructionpointer will JUMP to Label_P instead of Label_O. TheUpdate-Processing-Routine can be shown as follows using programdescription language, which can be translated into C/C++/Java/Assemblerand other software programming languages, or executable machine code ofCPU/Microprocessor and DSP: (At the beginning of a software section, incase that there is a patch for updating this section) Jump to Label_PLabel_P: Patch-Correction-Routine Label_O: ORIGINAL SOFTWARE CODE

[0062] In this case, the CPU/Microprocessor or DSP instruction pointerwill be directed to the Patch-Correction-Routine. The design schemes ofthe Patch-Correction-Routine have been discussed in the previous section3.3.1. It should be noted that in FLASH memory, changing a value from“1” to “0” is allowed, while changing from “0” to “1” is not allowed.Therefore, by setting the initial jump offset as hexadecimal “0×FFF”allows decreasing the offset during patch programming.

[0063] 3.3.3 Designing Update-Processing-Routine using DirectJump/Branch Instructions

[0064] The following description illustrates another exemplary designand implementation of the Update-Processing-Routine in accordance withone embodiment of the present invention. When there is no correspondingpatch programmed in the patch area for updating the section, theUpdate-Processing-Routine can be shown as follows using programdescription language, which can readily be translated intoC/C++/Java/Assembler and other software programming languages, orexecutable machine code of CPU/Microprocessor and DSP: (At the beginningof a software section in case of no patch programmed) Jump to Label_OLabel_O: ORIGINAL SECTION CODE

[0065] When there is no corresponding patch programmed in the patch areafor updating the software section, the first and the only instruction ofthe Update-Processing-Routine is to JUMP to Label_O, which is the startaddress of the original code of the section.

[0066] When there is a corresponding patch programmed in the patch areafor updating the software section, the first and the only instruction ofthe Update-Processing-Routine will be changed, so that the CPU/DSPexecution will be directed to the start address of aPatch-Correction-Routine or the start address of patch program. TheUpdate-Processing-Routine can be shown as follows using programdescription language, which can be translated into C/C++/Java/Assemblerand other software programming languages, or executable machine code ofCPU/Microprocessor and DSP: (At the beginning of a software section, incase that there is a patch for updating this section)   Jump toPatch-Correction-Routine (or Patch Start Address) Label_O:  ORIGINALSECTION CODE

[0067] The design schemes of the Patch-Correction-Routine have beendiscussed in the previous section 3.3.1.

[0068] The following description illustrates an example of using ARMS(Advanced RISC Machines) CPU assembly language, especially, for the ARMmode that uses 32-bit instruction set. (At the beginning of a softwaresection, in case of no patch programmed) B  Label_O Label_O:    ORIGINALSECTION CODE

[0069] In this example, the branch instruction “B” of ARM CPU is used asthe Update-Processing-Routine. Because it jumps to the next line, itsoffset becomes “0×FFFFFF”. Because a bit in FLASH memory can be changedfrom “1” to “0” during FLASH programming, this offset value “0×FFFFFF”can be easily changed to any other 24-bit values in FLASH programmingprocess.

[0070] After a patch for updating this section is received, the patchprogram is written into patch program area. The “B” instruction offsetwill be changed from “0×FFFFFF”, corresponding to jumping to Label_O, toan offset value corresponding to jumping to the start address of patchprogram. (At the beginning of a software section, in case that there isa patch for updating this section) B  Patch_Start_Address Label_O:ORIGINAL SECTION CODE

[0071] 3.4 Software Updating based on Patch-Operation-Area

[0072] This section introduces techniques to allocate or reservePatch-Operation-Areas for patch operation in a software program. APatch-Operation-Area is defined as a memory area or a block of databytes that can be used for patch operation. It can be, for example, thememory area for containing the Update-Processing-Routines described inthe above sections, the memory area for storing the JUMP commands fordirecting CPU/DSP instruction pointer to the start address of a patchprogram, the memory area for storing the Patch-Control-Routines, and thememory area for containing patch program.

[0073] Similar to the section 3.1, a group of locations L1, L2, . . . ,Ln, in the order from small address to large address, should bedetermined at first. Accordingly, the embedded software is effectively“separated” into a plurality of software sections, S1, S2, . . . , Sn. APatch-Operation-Area is allocated or reserved at some or most, if notevery, location of L1, L2, . . . , Ln. Some Patch-Operation-Areas canalso be inserted or reserved at the end of the embedded software, or ata location of memory area outside of the embedded software code area.

[0074] Some implementations may also directly reserve memory areas inthe original embedded software, and use these memory areas as thePatch-Operation-Areas for updating the embedded software. In this case,the above term “allocating” is more akin to “reserving” memory areas bysome instructions of the embedded software.

[0075] When a Patch-Operation-Area is defined and used as anUpdate-Processing-Routine, it can be placed in each software section ofthe embedded software as shown in the above sections.

[0076] In the following, an example is shown of allocating/reserving thePatch-Operation-Areas into assembler program. In an assembler program,normally we can declare certain data areas in assembler instructions anduse the data areas to contain certain constant parameters or a block ofdata. Based on this feature, we can declare certain data areas insoftware program and use the data area especially for software patchoperation. When FLASH memory is used in digital products to containsoftware program, certain data areas can also be declared as beingfilled with “0×FF” hexadecimal numbers. As such, later on, patchingprocess can easily change these “0×FF” hexadecimal numbers into patchprogram codes, such as the program codes of thePatch-Correction-Routines, the program codes of thePatch-Control-Routines, or the program codes for updating a softwaresection or fixing an error. This is based on the fact that content in aconventional FLASH memory can only be changed from “1” to “0”, butcannot be changed-from “0” to “1”. We can also initially define certainprogram codes in the Patch-Operation-Area especially for patchoperation.

[0077] When the CPU runs to a software section that has a patch in thepatch program area for updating this section, the CPU instructionpointer should be directed to the place where the patch program starts,such as the patch start address 502 and 602 of FIG. 5 and FIG. 6,respectively. However, jump/branch assembler codes typically have theirmaximum jump range. For example, when an ARM CPU is in the THUMB mode,the maximum branch range of the branch assemble code B is only ±2048bytes. If the CPU instruction pointer cannot be shifted to the place ofthe patch start address with one jump/branch assembler code, multiplejump/branch codes can be used for long jumps. For example, when the ARMCPU is in the THUMB mode, we can use the Branch assemble code “B” andthe Long Branch With Link assemble code “BL” for a jump/branch longerthan ±2048 bytes. And we need to reserve the Patch-Operation-Area forthese multiple jump/branch codes. In the following, we describe atechnique to save memory space when allocating the Patch-Operation-Areafor these jump/branch codes.

[0078] First, we insert a jump/branch command into every softwaresection. For example, when the ARM CPU is in the THUMB mode, we insertthe jump/branch assemble code “B” that has maximum branch range ±2048bytes. We set offset of this jump/branch command so that it jumps to thenext command. Therefore, the result of CPU operation is the same as theoriginal code without this jump/branch command. This scheme has beenshown in Section 3.3.3.

[0079] A Patch-Operation-Area may contain an area for aPatch-Control-Block. A Patch-Control-Block functions as thePatch-Control-Routine and may contain the secondary jump/branchcommands. When a FLASH memory is used, the Patch-Control-Block can bedeclared as being filled with “0×FF” hexadecimal numbers. As such, FLASHprogramming of the patching process can easily change these “0×FF”hexadecimal numbers into any program code, such as secondary jump/branchcode. Multiple software sections may share one Patch-Control-Block.

[0080]FIG. 7 shows how an exemplary Patch-Control-Block handles the jumpto patch program area. A short jump 706 takes the execution fromsoftware section 710 to Patch-Control-Block 709, which works as aPatch-Control-Routine. A second jump 711 takes the execution to patchstart address 702 of patch program 707. Upon execution of patch program707, it jumps back to end of the software section 710.

[0081] The following example program written with software descriptionlanguage shows a Patch-Control-Block is shared by four softwaresections, Section-A, Section-B, Section-C, and Section-D. In thisexample, the Patch-Operation-Area of Section-A is defined as anUpdate-Processing-Routine “Jump to Label_O_A”; the Patch-Operation-Areaof Section-B is defined as an Update-Processing-Routine “Jump toLabel_O_B”; the Patch-Operation-Area of Section-C is defined as a datablock area of N bytes being filled with hexadecimal 0×FF, which is usedas a Patch-Control-Block and an Update-Processing-Routine “Jump toLabel_O_C”; the Patch-Operation-Area of Section-C is defined as anUpdate-Processing-Routine “Jump to Label_O_D”. (At the beginning ofSection-A, when there are no patches for updating Section-A. Jump toLabel_O_A Label_O_A: ORIGINAL SECTION-A CODE (At the beginning ofSection-B, when there are no patches for updating Section-B) Jump toLabel_O_B Label_O_B: ORIGINAL SECTION-B CODE (At the beginning ofSection-C, when there are no patches for updating Section-C) Jump toLabel_O_C Declare a data block area of N bytes being filled withhexadecimal 0xFF, which is used as a Patch-Control-Block. (0xFF, 0xFF,..., 0xFF) Label_O_C: ORIGINAL SECTION-C CODE (At the beginning ofSection-D, when there are no patches for updating Section-D Jump toLabel_O_D Label_O_D: ORIGINAL SECTION-D CODE

[0082] Upon receiving a software patch, the patching process startsFLASH programming process to change the offset of the jump/branchcommand in the corresponding software section, and also change somebytes in the corresponding Patch-Control-Block from “0×FF” into thesecondary j ump/branch command, or some DSP/CPU instruction code workingas the Patch-Correction-Routine that has been discussed in Section3.3.1. For example, upon receiving a patch for updating Section-A, thefirst several bytes in the Patch-Control-Block will be changed to theinstructions of the Patch-Correction-Routine of Section-A. And uponreceiving a patch for updating Section-D, the next several bytes in thePatch-Control-Block will be changed to the instructions of thePatch-Correction-Routine of Section-D. These Patch-Correction-Routineswill direct CPU/DSP instruction pointer to the start address of a patchprogram. (At the beginning of Section-A, when there is a patch forupdating Section-A. Jump to Label_P_A Label_O_A: ORIGINAL SECTION-A CODE(At the beginning of Section-B, when there are no patches for updatingSection-B) Jump to Label_O_B Label_O_B: ORIGINAL SECTION-B CODE (At thebeginning of Section-C, when there are no patches for updatingSection-C) Jump to Label_O_C Data block area of N bytes, which is usedas Patch-Control-Block   ( Label_P_A: Patch-Correction-Routine ofSection-A Label_P_D: Patch-Correction-Routine of Section-D Otherremaining bytes 0xFF, 0xFF, ..., 0xFF   ) Label_O_C: ORIGINAL SECTION-CCODE (At the beginning of Section-D, when there is patch for updatingSection-D Jump to Label_P_D Label_O_D: ORIGINAL SECTION-D CODEL

[0083] In the following, we will introduce a technique to reduce thesize of the Patch-Control-Block. In some cases where it is important tosave FLASH memory or there are some restrictions on using memory space,it becomes necessary to reduce the FLASH memory usage as much aspossible. One way to reduce FLASH memory usage for patch operation is toreduce the size of the Patch-Control-Blocks. In the above example, thePatch-Control-Block is shared by four software sections, Section-A,Section-B, Section-C and Section-D. However, if the probability that allthese four sections have their corresponding patches simultaneously isvery low, then the size of a Patch-Control-Block can be designed in sucha way that it only has the space for handling three software sections orjust two software sections.

[0084]3.5 Compilation Upon Allocating Patch Operation Routines

[0085] After allocating the Update-Processing-Routines or thePatch-Operation-Areas in the original embedded software, somecomplications may occur when we compile the software.

[0086] In the following, we introduce a technique to avoid program wordalignment problem in compilation. As stated in the above, for eachsoftware section, an Update-Processing-Routine can be allocated forchecking whether there is a patch in the patch area for updating thissection. We can also allocate Patch-Control-Blocks in program code bydeclaring multiple blocks of memory space between assembler codes asparameter data area that can be used as the Patch-Operation-Area tocontain the secondary jump/branch commands. However, the code insertionmay cause some complications in compilation. For example, during programcompilation, some CPUs may request program word alignment. For example,when using an ARM CPU in the THUMB mode, assembler code LDR may need anoffset address that can be divided by 4 bytes. Therefore, when we insertthe jump/branch commands and Patch-Control-Blocks for patch operation,we need to adjust the bytes we insert so that the offset address of LDRcan be divided by 4 bytes. That is, by adjusting the bytes inserted forpatch operation, we can avoid program word alignment requirements incompilation.

[0087] In the following, we introduce a technique to avoid offset out ofrange issue in compilation. For example, when using the ARM CPU in theTHUM mode, assembler code LDR can be used to load some data at offsetless than 2048 bytes from the LDR code. If some codes being inserted forpatch operation between the LDR and the offset address contain some datato need to be loaded, the offset value of LDR code can be larger than2048 bytes, causing compilation problems. One technique to avoid suchkind of problems is to move the data that need to be loaded to a placethat is closer to some assembly code (such as LDR code) so that theoffset value can be less than 2048 bytes. That is, by moving or copyingthe data that need to be loaded by some assembler codes. (such as LDR)to places that are closer to the assembler codes (such as LDR) that loadthe data, we can avoid “out of range “problems in compilation for someassembler codes.

[0088] Similarly, after allocating some patch process related bytes intothe embedded software, some original program code, such as B command ofthe ARM assembler code, may become out of range, i.e., destinationbecomes too far for B to jump to. Inserting another jump/branch commandbetween the B and the destination can prevent the “out of range” problemin compilation. That is, jumping twice for a long jump.

[0089] 3.6 Update Patch Program With New Patches

[0090] After a digital product successfully programs a received patch,it will start to use the instead of executing the corresponding originalcode in the software section. However, even the programmed patch programmay still have some problems sometimes, or the patch program isnecessary to be updated after a period of time. A technique of updatingthe patch program is now described as follows.

[0091] In order to update a patch that has been programmed in thedigital product, a new patch can be made to update the patch. To supportthis feature, when a patch is being designed, some code space for patchoperations of new patches in the future should be reserved; or similarto updating a software section described in the previous sections, anUpdate-Processing-Routine can be inserted to the patch program.Therefore, when CPU/DSP runs to a software section of an old patch thathas a new patch for updating, the CPU/DSP pointer can be directed to usethe new patch program instead of using old patch program, by theUpdate-Processing-Routine.

[0092] All the techniques described in this application for designing apatch for updating a software section of a software program can be usedfor designing a patch for updating another existing patch.

[0093] 3.7 To Avoid Effects Of Compiler Optimization Process

[0094] Embedded software can be written with C/C++/Java/Assembler orother software programming languages. If a software program is notwritten with Assembler code, but with C/C++/Java or other softwareprogramming languages, the program can be translated into assembler codeby using software compiler tools. Software compiler tools may performoptimization processes on the software program, and may change/optimizethe original program during compilation that transforms the programwritten in C/C++/Java or other software programming languages intoobject code or assembler code. Because of this optimization, someprogram code may disappear. Therefore, if we allocate theUpdate-Processing-Routines directly into the C/C++/Java program, theUpdate-Processing-Routine may be changed or removed during the processof compiler optimization. However, after compilation, normally there areno code optimization processes at the stage of transforming assemblercode into object code, and also there are no code optimization processesat the stage of linking object codes into final executable machine codewith software linker tools.

[0095] A software program written in C/C++/Java and other softwareprogramming languages can be compiled in the following two ways.

[0096] Compilation-Method-1: Transform the program code written inC/C++/Java language into object code using software compiler tools(maybe with optimization process). Then, link object codes to generateexecutable machine code with software linker tools.

[0097] Compilation-Method-2: Transform the program code written inC/C++/Java language into assembler code using software compiler tools(maybe with optimization process). Then, transform the assembler codeinto object code using software assembler tools. Then, link object codesto generate executable machine code with software linker tools.

[0098] Normally, the final executable machine code generated byCompilation-Method-1 is identical to the final executable machine codegenerated by Compilation-Method-2. If a software program is directlywritten in assembler language, we can transform the program into objectcode using software assembler tools. Then, link object codes to generateexecutable machine code with software linker tools.

[0099] A technique described herein to allocate theUpdate-Processing-Routines and the Patch-Operation-Area into a softwareprogram is to use the Compilation-Method-2. In the Compilation-Method-2,after transforming the program code written in C/C++/Java language intoassembler code using software compiler tools (may with optimizationprocess), the Update-Processing-Routines, the Patch-Control-Routines,and the Patch-Operation-Area can be inserted into the assembler code.Because there will be no optimization processes that may change oroptimize software code in the compilation processes of transforming theassembler code into object code and linking object codes to generateexecutable machine code, the patch routines and patch program space canremain intact.

[0100] Another method can be that, transform the program code written inC/C++/Java or Assembler language into object code, then insert theUpdate-Processing-Routines, the Patch-Control-Routines, or thePatch-Operation-Areas into the object codes. And then, link object codesto generate executable machine code with software linker tool. 3.8Allocating Patch Operation Routines with Software Tools

[0101] Anther aspect of the present invention is the methodology toallocate or insert the aforementioned Update-Processing-Routines andPatch-Operation-Area into the embedded software of the digital products,such as cellular phones. As digital products are manufactured inproduction, they must be programmed with embedded software to becomeoperational, before they can be released to market. TheUpdate-Processing-Routines and/or Patch-Operation-Area should preferablybe allocated in embedded software of digital products, before thedigitals products are programmed with the embedded software.

[0102] To efficiently allocate the Update-Processing-Routines and thePatch-Operation-Area into the embedded software of digital products,another aspect of the present invention provides an allocation softwaretool for automatic allocation.

[0103] One embodiment of the allocation tool integrates the allocationprocess with the compilation process of the embedded software. Forexample, prior to the compilation of the source code, the allocationtool can be started automatically to finish the allocation. In this way,software developers will just concern themselves with their originaltask of code development, without getting involved in or worrying aboutthe allocation process.

[0104] For example, one embodiment of the allocation process may beperformed on the assembler code instead of on the C/C++/Java code. Inthis situation, C/C++/Java code will first be compiled into thecorresponding assembler code, and then, the allocation process will beperformed on the generated assembler code to insert theUpdate-Processing-Routines and Patch-Operation-Area. Then, the assemblercode will be further compiled into object code. In this way, anyoptimization processes in the compliers of C/C++/Java code will notaffect the Update-Processing-Routines and the Patch-Operation-Area.

[0105] Two examples of the allocation software tool are shown asfollows, although those skilled in the art can readily develop their ownallocation tool based on the teaching of the present invention.

EXAMPLE-A

[0106] For every N lines (or bytes) of the software code, where N is apredefined number and the software code may be written inC/C++/Java/Assembler and other software programming languages, orexecutable machine code of CPU/Microprocessor and DSP, the allocationtool inserts an Update-Processing-Routine and/or a block ofPatch-Operation-Area into the software code. The allocation tool mayalso change the parameters and labels in the Update-Processing-Routineaccording to the corresponding section identifier when necessary. Theallocation is operated directly in the original files that contain thesource code of the embedded software.

EXAMPLE-B

[0107] In some applications, the embedded software of a digital producthas more than one files that contain the source code of the embeddedsoftware. For each file, the allocation tool generates another file thatcontains the same software code as the original file, i.e., making acopy of the file. Then, the allocation tool will insert theUpdate-Processing-Routines and/or Patch-Operation-Area into theduplicate files, instead of using the original files. That is, for everyN lines (or bytes) of the software code in the generated files, where Nis a predefined number and the software code may be written inC/C++/Java/Assembler and other software programming languages, orexecutable machine code of CPU/Microprocessor and DSP, the allocationtool inserts an Update-Processing-Routine and/or a block ofPatch-Operation-Area into the software code. The allocation tool mayalso change the parameters and labels in the Update-Processing-Routineaccording to the corresponding section identifier when necessary.

[0108] 4. Patch Transmission and Patch Receiving

[0109] 4.1 Patch Data Transmission.

[0110] First, we describe how the software patch may be transmitted froma patch server (to be described below) to digital products. An exampleof transmitting patch data using certain communication layers is shownin FIG. 8. Some implementation may only include one or two of the threelayers for controlling patch data transmission, depending on thetransmission design schemes and needs. Some other implementation may usedata transmission channels or transmission path, such as circuit datatransmission or packet data transmission. Some other implementation mayuse voice or video transmission channels, by putting patch data intothese channels or transmission paths and send the patch data to digitalproducts.

[0111] By “patch server,” it should be appreciated by those skilled inthe art that it may be a system that can dispatch or transmit a softwarepatch to one or more digital products in the field, preferably throughexisting communication infrastructure or channels, such as a wirelesslink, or a wired connection. The patch server may have any level ofautomation for its operation. Upon transmission, a digital productreceives patch data with its Patch Receiving Module 302 shown in FIG. 3.

[0112] During or after the patch data transmission, the digital productmay send signals (or messages) to the patch server for acknowledgment.Another example is that, the digital product may send signals (ormessages) to a Patch-Reply-Message-Collector, instead of a patch server.Then, the Patch-Reply-Message-Collector will send a corresponding signaland data to the patch sever. The Patch-Reply-Message-Collector is amessage receiver that collects reply message from the digital products.It can be located at a different place from the patch server.

[0113] For digital cellular phones using CDMA technology based onTIA/EIA-95 and CDMA2000 standards, Data Burst Messages can be used tocarry patch data. One example of using the Data Burst Messages is to usethe SMS message transmission based on TIA/EIA-637 standard. In thefollowing, an example of using the SMS messages to deliver patch datawill be described, although those skilled in the art of datatransmission may readily devise their own delivery mechanism using othersignal messages. Since there are already error detection processes inthe communication protocol of SMS message transmission (TIA/EIA-637),using SMS as a lower layer for patch transmission, digital product willreceive nearly-error-free patch data packets.

[0114] With reference to FIG. 8, an exemplary Link Layer 820 for patchtransmission in accordance with one embodiment of the present inventionwill now be described. Link Layer 820 is to reliably transmit patchsignaling messages 800 and patch data 810 by detecting transmissionerrors and performing retransmission in error cases. Error detection canbe based on CRC (Cyclic Redundancy Codes), checksum or other schemes ascan readily be implemented by those skilled in the art. Link Layer 820may also include security check mechanism. For example, before patchdata is sent out, the patch server may encrypt the patch data with someencryption algorithm and then send the patch data to digital products.When a digital product receives a patch, it will perform decryptionalgorithm on the patch data to check correctness of the received patchdata.

[0115] In an exemplary use of SMS messages, after a patch data packetcarried by an SMS message is received, the message is passed to thedecryption module where CRC checking process and message decryptionprocess are performed to check the correctness of the patch data packet.

[0116] In the event that a digital product cannot correctly receivepatch data, the patch server shall re-send the patch data to the digitalproduct. For example, patch retransmission can be based on a timer-basedmechanism: The patch server has a timer for patch retransmission. Afterthe patch server sends out a patch to a digital product, it will startthe timer. If the patch server does not receive any corresponding replymessage (e.g., patching status report) from the digital product when thetimer times out, the patch server will re-send the patch data packets tothe digital product. In some special cases where a patch server does notreceive any reply messages from the digital product after the patchserver has performed patch re-transmission for a predetermined number oftimes, the patch server may stop the retransmission for a while. Itshould be appreciated by those skilled in the art that other ways oftiming the transmission and re-transmission of patches can readily beimplemented in connection with the teaching of the present invention.

[0117] In the previous example of using SMS messages, there is one patchsignaling message named Patch Status Report, which is sent from adigital product to a patch server and contains the current patch statusinformation of the digital product. If the digital product receives apatch without error, it will send Patch Status Report via a reverse SMSmessage to the patch server at the time:

[0118] (a) when the digital product finds out that the received patchhad been already programmed successfully, or

[0119] (b) when the digital product successfully finishes the patchprogramming.

[0120] 4.2 Patch Data Composition.

[0121] With reference to FIG. 9, the composition of patch data 940 isnow further described. Patch data 940 is preferably separated intoseveral patch data packets, and one patch data packet can be carried byone message of the relay layer 820.

[0122] In the exemplary use of SMS messages, one patch data packet maybe carried by one SMS message. In order to identify a patch SMS messagefrom other regular SMS messages, the first “k” characters (where “k” isa pre-defined number that can be assigned from zero to any positivenumber) of the User Data in a patch SMS message can be set to ak-character Magic-Word by the patch server before patch delivery.Following the Magic-Word, a patch data packet is inserted into a SMSmessage.

[0123] The relation between patch data and patch data packets is shownin FIG. 9. A patch data packet 950 can be separated into packet overheadfield 945 and payload data field 947. A design example of the packetoverhead 945 may contain the following information:

[0124] (a) Patch Identifier

[0125] (b) Current Packet Number

[0126] (c) Last Packet Number

[0127] It should be appreciated by those skilled in the art that otherways of design packet overhead for transmitting patch data packets canreadily be implemented in connection with the teaching of the presentinvention.

[0128] The payload data 947, 955, 965 in the patch data packet 950 maycontain the whole or one part of patch data 940.

[0129] The patch data packet 950 may be encrypted by the patch serverwith some encryption algorithm before transmission. The patch server mayencrypt the software patch data by using static and/or dynamic keys: theformer can be a CPU identifier, MAC layer address and othertelecommunication service related parameters, such as directory number,ESN and TMSI temporary identifications; the later are changeable keysbased on location or time or user's profile.

[0130] 4.3 Patch Data Processing.

[0131] After receiving a message that may carry a patch data packet 950,the digital product will check whether the message contains a real patchdata packet. The digital product may also perform error detection and/ordata decryption on the received message. After successfully receivingall the necessary patch data packets, the digital product will composethe corresponding patch data from the payload data 947, 955, 965 in thepackets.

[0132] In the exemplary use of SMS messages, when the digital productreceives an SMS message, it will check whether the predetermined first kcharacters in the message are identical to the Magic-Word. If there is amismatch, the SMS message will be treated as a regular SMS message, nota patch data packet.

[0133] If there is a match, the digital product will further try todecrypt the message data to check the correctness of the message. If thedecryption process shows that the message data is correct, the messagedata will be treated as a patch data packet, and a buffer may be used tocontain the data. Otherwise, the SMS message will be treated as aregular SMS message.

[0134] After successfully receiving all the necessary patch data packetsbased on the information items of the Patch Identifier, theCurrent-Patch-Number and the Last-Patch-Number in the received patchdata packets, the digital product will compose the corresponding patchdata from these packets.

[0135] The patch data 940 may include some of the following items, suchas:

[0136] (a) Items to identify whether the received patch is for thedigital product, for example,

[0137] ESN (Electronically Serial Number)I

[0138] MIN (Mobile Identification Number) or IMSI (International MobileStation Identity);

[0139] Manufacture Identifier;

[0140] Product model number;

[0141] Software version number;

[0142] CPU Identifier;

[0143] MAC (Medium Access Control) layer address;

[0144] Other items that can be used for identifying a digital product;

[0145] Other items that can be used for identifying a subscriber.

[0146] (b) Items for patch programming, for example,

[0147] Control information to indicate that some patch data should bewritten into FLASH memory, and/or some patch data should be written intoNVM (Non Volatile Memory) memory and/or EEPROM (Electrically ErasableProgrammable Read-Only Memory) memory;

[0148] Address information of patch data, which may be memory addresses,sector allocation information or other types of address information ofFLASH(NVM/EEROM memory in digital product;

[0149] Patch program codes that can be used for software updating;

[0150] Information of how to interpret patch program codes. For example,the programming language information (C/C++/Java/Assembler and othersoftware programming languages, or executable machine code ofCPU/Microprocessor or DSP) that is used in the patch program codes;

[0151] Patch data that can be used for updating some data area or datatables in FLASH memory, NVM, and/or EEPROM memory;

[0152] Software Section Identifiers of the software sections that areupdated by this patch;

[0153] Other information to describe patch program and data area update.

[0154] (c) Items for patch programming post-process, for example,

[0155] Reset Flag.

[0156] Control flag for sending response messages to patch server.

[0157] Other control signal and data for the post-process of patchprogramming.

[0158] After the received patch data is composed, the digital productmay preferably perform decryption process on the composed patch datawhen necessary. This is to enhance the security checking on patch data.Of course, the patch server side should perform encryption on the patchdata before separating them into patch data packets for transmission.

[0159] The patch program codes may be written in C/C++/Java/Assemblerand other software programming languages, or executable machine codes ofCPU/Microprocessor or DSP. The patch data may include someinterpretation information for the patch program codes. If the patchprogram codes can be interpreted based on the interpretationinformation. Some implementations may include a software module ofinterpreter to translate the received patch program from one format toanother format. In some implementations, patch program can alsointerpreted or translated into CPU/DSP executable machine codes whenCPU/DSP wants to use the patch program.

[0160] The patch program contains the software update information to beused as a substitute of a piece of the original program in the embeddedsoftware. The patch program may be made to start from a Patch StartAddress. Also, for example, and at the end of a patch program, there canbe an instruction for jumping back to a predetermined place in theembedded software where the original obsolete/error code has beenskipped, or the end of that block of the original obsolete/error code.

[0161] The patch data may also contains information for updating dataarea of FLASH memory, NVM, and/or EEPROM memory. For example, the patchdata may contain a new data table for replacing an old data table in NVMmemory of a digital product

[0162] The digital product may check if certain information items, forexample, ESN, Manufacture Identifier, Product Model Number and SoftwareVersion Number, are identical to that stored in the digital product. Ifthere is a mismatch, the digital product may discard the patch data (ortreat those messages as regular SMS messages in the example of using SMSmessages). If they are matched, the digital product may further checkwhether the received patch data have been programmed into the memory ofthe digital product. If not, the digital product will start to programthe received patch data. Otherwise, the digital product may send a patchresponse message to the patch server, and finish the patching process.

[0163] 5. Patch Programming

[0164] Patch programming involves writing patch data into thecorresponding patch area in the FLASH memory, and/or writing newparameters into NVM/EEPROM memory. Patch programming is preferablyperformed when the digital product is idle (i.e., not being used by theuser). Writing new parameters into NVM/EEPROM memory can be readilyperformed using some regular data overwriting process on NVM/EEPROMmemory. However, writing data into FLASH memory, especially when theFLASH memory is being read by the digital product may require additionalhandling in some cases. In order to perform the patch programming on theon-the-fly digital products, a technique of programming FLASH within aRAM memory is described in accordance with one embodiment of the presentinvention.

[0165] 5.1 FLASH Programming using RAM Memory

[0166] The software routine for writing data into FLASH memory can beput into RAM memory. There are several ways to put the software routineinto RAM memory as can be appreciated by those skilled in the art. Forexample, the software routine for writing data into FLASH can be copiedinto RAM memory by a software routine, before FLASH programming. Anotherexample is that, when we compile the embedded software, we can instructthe compiler to assign the FLASH programming routine to be allocatedinto RAM memory, so that compiler automatically allocates the routineinto the RAM memory. The RAM memory can be the type of on-chip RAM/SRAMmemory that is in the chip containing CPU/DSP core, or RAM memoryoutside the chip that contains the CPU/DSP. When it is necessary towrite patch related data into FLASH memory, the software routine forFLASH programming can be executed in the RAM memory. The routine writesdata byte into the corresponding FLASH address, reading the FLASH statusvalue, and checking the correctness and completion of the data writing.The task of the FLASH programming function is preferably set at thehighest priority level, and also when it starts to run, it preferablyfirst disables all CPU/DSP interrupts, so that while it is running, allthe other software tasks and all CPU/DSP interrupts stop and wait.

[0167] An alternative way is to run the FLASH programming routine in aninterrupt handler, and when the routine starts to run, it willpreferably first disables all the other interrupts, so that while it isrunning, all software tasks and CPU/DSP interrupt routines stop and wait

[0168] Another alternative way to ensure no influences come from othersoftware tasks and interrupt routines during FLASH programming is,before starting FLASH programming routine, stopping softwaretasks/threads that are not related to the FLASH programming or softwarepatch process and also disabling those unrelated interrupt routines thatare not related to the FLASH programming or the software patch process.

[0169] 5.2 Patch Programming Process

[0170] The patch programming process may be divided into severalsub-states, one exemplary of which is shown in FIG. 10. Uponsuccessfully receiving patch data, the digital product will write thepatch data into the FLASH memory, NVM and/or EEPROM memory of thedigital product.

[0171] If some patch data are used for updating data area or data tablesin FLASH memory, NVM, and/or EEPROM memory, the digital product shallwrite the data into the corresponding address of the FLASH memory, NVM,and/or EEPROM memory.

[0172] If some patch data are used for updating program code of somesoftware sections, the digital product shall write the patch programcode into the corresponding address of the FLASH memory.

[0173] Then, the digital product may start to write patch identificationinformation into the Patch-Control-Table 1020 or some kinds of patchdatabase. The patch identification information may include informationof patch address, Patch Identifier, and software section identifier,etc.

[0174] Then, the digital product will go to the next step of the SectionStatus Programming 1030. Depending on the scheme of designing theUpdate-Processing-Routines as previously described, theUpdate-Processing-Routine of a software section may contain either oneor two JUMP instructions, or a Patch-Checking-Routine that may check apatch flag. After the patch program has been programmed successfully, ifthe Update-Processing-Routine is using patch flags, the correspondingpatch flag will be changed to reflect the patch existence; if theUpdate-Processing-Routine is using JUMP instructions, the correspondingJUMP offset shall be changed, so that CPU/DSP instruction pointer willJUMP to the corresponding patch start address. Some data bytes in thePatch-Control-Block and/or in the Patch-Operation-Area may need to bechanged by the FLASH programming routine. The detailed changes for theUpdate-Processing-Routines from the status without a patch programmed tothe status with a patch programmed, and the changes on thePatch-Control-Blocks have been described in previous sections.

[0175] Programming the key JUMP offset or patch flag change in theUpdate-Processing-Routines should preferably be at the last, so that thedigital product will not malfunction if patch programming is stopped inany time. For example, for changing the Update-Processing-Routine ofSection-A previously described in Section 3.4, the digital product shallfirst change the data bytes in the Patch-Control-Block to theinstructions of the Patch-Correction-Routine of Section-A at theLabel_P_A. Then, change the Jump to Label_O_A to Jump to Label_P_A bymodifying the offset of the JUMP instruction. In this way, switching touse the patch program instead of using the original code will beperformed only when all the programming processes are completed.

[0176] When patch programming is successfully completed, the digitalproduct will perform some post processes, such as sending patch statusmessage to the patch server, and/or performing system reset ifnecessary. In the exemplary use of SMS messages, the digital product mayperform the post-process shown in the following:

[0177] the digital product will send a Patch Status Report via a SMSmessage to the patch server. The patch status report contains theterminal information and the current patching status;

[0178] And then, if the Reset-Flag in the patch data is set, the digitalproduct performs system reset.

[0179] 6. Patch Server

[0180] Reference is now to FIG. 11, where a simplified diagram of anexemplary patch server 1100 is illustrated. A patch server 1100preferably has a patch database 1130, a patch generator 1110 and a patchtransmission controller 1120.

[0181] The patch database 1130 stores patch information in connectionwith each of the digital products. It may also store the followingitems:

[0182] (a) Manufacture Identifier;

[0183] (b) Product model number;

[0184] (c) Software version number;

[0185] (d) Software Section Identifier;

[0186] (e) Patch Identifier;

[0187] (f) CPU identifier;

[0188] (g) MAC (Medium Access Control) layer address;

[0189] (h) Other items that can be used for identifying a digitalproduct;

[0190] (i) Other items that can be used for identifying a subscriber;.

[0191] (j) Patch Address Information;

[0192] (k) Reset Flag Information;

[0193] (l) Patch program code.

[0194] (m) Information of how to interpret patch program codes. Forexample, the programming language information (C/C++/Java/Assembler andother software programming languages, or executable machine code ofCPU/Microprocessor or-DSP) that is used in the patch program codes;

[0195] (n) Data parameter for updating data memory area (NVM/EEPROM) ofthe digital products.

[0196] When the patch server is to deliver a patch to a digital product,the patch generator 1110 generates a corresponding patch data based onthe data stored in the Patch Database 1130. The patch generator 1110 mayfurther separate the patch data into several sections and put eachsection into a patch data packet for transmission when the patch datacan not be carried by a single patch data packet.

[0197] The patch transmission controller 1120 is to reliably deliver thepatch data packets to the digital product. One exemplary design is toinclude a timer for patch retransmission and its design details areshown in the following.

[0198] After the patch server sends out a patch to a digital product, itstarts a timer. If the patch server does not receive any correspondingreply message (e.g., patching status report) from the digital productwhen the timer times out, the patch server will re-send the patch datapackets to the digital product. In some special case where the patchserver does not receive any reply messages from the digital product whenthe patch server has performed patch retransmission for a predeterminednumber of times, the patch server may suspend the retransmission for awhile, or just suspend the timer permanently and record the lack ofreply in a log file.

[0199] Upon receiving a reply message (e.g., patching status report)from a digital product, the patch server will stop the timer of patchretransmission, and update the patching status of the digital product inthe patch database.

[0200] In the following, an exemplary design is described to show how asoftware patch is transmitted via SMS messages from the patch server todigital products. This exemplary design is described with reference toFIG. 12.

[0201] In this exemplary design, the digital products with embeddedsoftware are cellular phones 1250. The patch server hardware isimplemented by a computer 1200 and a wireless modem 1210 that is capableof receiving SMS messages. The computer generates patch data andcorresponding patch SMS Messages and then sends the messages through theInternet 1205 to a message server 1240 of the service provider thatprovides the wireless services to digital products 1250. The messagedelivery to the message server can be based on regular emailtransmission method using SMTP (Simple Mail Transfer Protocol) andTCP/IP. The message server 1240 of the service provider then transfersthe patch SMS messages as regular SMS messages 1225 to base stations1220. Finally, the base stations 1220 deliver the messages 1225 tocorresponding cellular phones 1250 through some air messages, such as,the Data Burst Messages that carrying the SMS messages 1225.

[0202] The wireless modem 1210 of the patch server is attached to thecomputer 1200 of the patch server. The wireless modem is to receivereply messages 1215 from digital products 1250 and transfer the replymessages 1215 to the computer 1200. The computer 1200 will confirm thepatching status based on the information carried by the reply messages1215.

[0203] Although the invention is described herein with reference to thepreferred embodiment, one skilled in the art will readily appreciatethat other applications may be substituted for those set forth hereinwithout departing from the scope of the present invention. Accordingly,the invention should only be limited by the claims included below.

[0204] Glossary of Abbreviations

[0205] ARQ. Automatic Repeat request.

[0206] CPU. Central Processing Unit.

[0207] CRC. Cyclic Redundancy Codes.

[0208] DSP. Digital Signal Processor

[0209] EEPROM. Electrically Erasable Programmable Read-Only Memory.

[0210] ESN. Electronic Serial Number.

[0211] FLASH. A type of constantly-powered nonvolatile memory that canbe erased and reprogrammed in units of memory called blocks.

[0212] MAC. Media Access Control.

[0213] MCU. Micro Processor Unit.

[0214] NVM. Non Volatile Memory

[0215] Patch data. Data of a total patch transmitted from patch serverto a digital product.

[0216] Patch data packet. Unit of patch data transmission. One patch canbe divided and transmitted with several patch data packets. One patchdata packet may be carried by one message.

[0217] Patch program. Software program used for software update, whichis composed by a one or multiple CPU/DSP instructions, for updating oneor multiple program codes of the existing embedded software.

[0218] Patch programming. Process to write patch data into memory.

[0219] Patch server. One or more server for transmitting patch data todigital products that support patching.

[0220] PCMCIA. Personal Computer Memory Card International Association.

[0221] PDA. Personal Digital Assistant.

[0222] RAM. Random Access Memory.

[0223] ROM. Read-Only Memory.

[0224] SMS. Short Message Service.

1-57. cancelled
 58. A computer readable medium comprising instructionsfor updating an embedded software for a digital product, comprisinginstructions for: executing said embedded software; determining whethera patch program is available for a section of said embedded software;directing execution of said embedded software at said section to saidpatch program if said patch program is available for said section;directing execution back to a predetermined location of said embeddedsoftware after execution of said patch program, wherein said embeddedsoftware is allocated with a plurality of routines adapted to determinewhether a patch program is available.
 59. A computer readable mediumcomprising instructions for updating an embedded software for a digitalproduct, comprising instructions for: executing said embedded software;determining whether a patch program is available for a section of saidembedded software; directing execution of said embedded software at saidsection to said patch program if said patch program is available forsaid section; directing execution back to a predetermined location ofsaid embedded software after execution of said patch program, whereinsaid predetermined location is an end to a program portion that needs tobe updated.
 60. The computer readable medium of claim 59, furthercomprising instructions for: receiving a patch program through acommunications link; programming said patch program into said digitalproduct.